Aug 94 Dialog Box
Volume Number: 10
Issue Number: 8
Column Tag: Dialog Box
Dialog Box 
By Scott T Boyd, Editor
Failure of OO Revolution?
On 6/5/94, vollrath@vax.ox.ac.uk wrote [in STA-FORUM@qks.com]:
I have been interested in Dylan since I first heard about it, although I have had
little solid information until recently. I hope it does well, and am reasonably confident
that it will. I certainly agree with its goals. I saw that in a recent edition of Byte they
said that the OO ‘revolution’ had failed, but sang the virtues of Visual Basic. It hasn’t
failed, it just hasn’t really started yet! All that has happened is that people that wrote
in C now right in a more complicated C. ‘Real’ dynamic-OOLs that provide a good and
convincing alternative to this haven’t really been around. Now, STA is one, Eiffel is
one, and I think Dylan will be one. ... portions deleted...
Most of you know that we have so enhanced and extended Smalltalk’s
capabilities/design in our Smalltalk product (SmalltalkAgents (STA)) that it is really
another generation of the Smalltalk language. Therefore, I will essentially punt on any
Dylan commentary since I have been answering such questions (regarding QKS activity
in this area) privately.
NOTES:
(1) Eiffel is not a (OODL) object oriented dynamic language and thus it suffers from
some of the same problems as C++ (it is still better than C++ in many ways).
(2) Dylan is function-centric, not object-centric. In Dylan, objects are just
structure, they do not have any inherent behavior. Modules (which contain
methods/unlike classes in other languages) become the behavioral scope and the
notions of OO such as inheritance are VERY different (i.e., sometimes they just
don’t exist in the language proper :-). STA has combined both class and module
style scope in our upcoming v1.2 release, thus libraries/projects can have both
public (unscoped) and (scoped) private methods that shadow class/object
methods for messages sent by methods in a library/project or one of its
sublibraries.
(3) The STA-Forum now has a fair number of subscribers who do not own (or
author in) SmalltalkAgents, but are on the forum to monitor technology trends.
(4) As most of you know, QKS’es Smalltalk (SmalltalkAgents) already has
components and we are making them really sophisticated in our upcoming
releases. We long ago committed to CIL/OpenDoc and will plug and play into other
component systems through whatever host services are available (like
SOM/DSOM).
I would like to make a few comments on the OO revolution failing: First, I think
it is an absurd statement. Component technology can only be layered on top of an OO
paradigm. What I mean by this is that components are like a 5GL given that I have a OO
substrate to build them on (the 4GL piece). Components are just objects with a
“well-known” messaging and data-interchange framework. For components to really
become successful the industry has to tackle the much harder problems of extensible
“framework” design, interaction, and validation.
I believe that componentization of system software and applications is just a
natural evolution of object technology. Saying OO has failed, seems as absurd as saying
that Ethernet/IP has failed now that we have Wide Area Networks and alternative
transports (i.e., now that the mass media has discovered the internet).
Most “complete” OO languages provide a rich set of frameworks that already have
a component based architecture. I think that it is really C++ with its non-dynamic
architecture and complex semantics/grammar that is failing.
I have to wonder what the BYTE author’s real knowledge, experience, or
awareness was to make such a public statement (in the corporate Smalltalk area alone,
I wonder what they thought IBM/Digitalk PARTS were?). We all know that IBM has
over 1.1 billion dollars of Smalltalk work on the books for 1994 (which they cannot
find skilled people to fulfill).
The corporate marketplace is bailing on C++ and demanding Smalltalk, with real
salaries for qualified corporate Smalltalk programmers typically ranging from
$1000 to $2000 per day. We also know that IBM has committed to moving all their
COBOL base onto Smalltalk - what does that tell you? OO really premiered with
Smalltalk (not SIMULA as some folks would have you believe), and Smalltalk still
epitomizes most if not all the OO principles (multiple inheritance excluded <== lack of
it is an arguable ST weakness).
It seems irresponsible to tout Microsoft’s (market-saturation of) VisualBasic
without carefully explaining the real issues of development today (which I think
involve productivity (environments, visual-tools, self-authoring-agents),
robustness, maintainability, scalable design, teams, and integration of independently
authored bodies of code [frameworks, fragments, components, etc]). It is this kind of
“promotion” that got us into the C++ mess in the first place...
The Windows/DOS world has been dominated so long by static C/C++ that when it
got a taste of dynamic/interactive languages via VisualBasic it reacted like a starving
person. It is really Microsoft who finally has begun to wake up to the problems of
C++, you watch...
As has been mentioned by folks on this forum and elsewhere, the real change that
is happening in software technology is that we are moving away from language issues
and onto design (object/framework interaction) and productivity issues. In this
evolving world, the capabilities of the development environments (integrated visual
tools and packaging are crucial) and the frameworks they provide become the critical
elements.
Building components in C++ is just as hard as building applications (talk to the
folks who are trying to do it). The real problem at hand is managing complexity and
capturing the design intent. The latter means that when I re-use or plug-in code
(including components) from some outside source, how do I know how it will behave
and how can I verify that it follows all my frameworks “rules”. All kinds of new
issues arise, e specially with regard to extensibility, negotion of services, access to
attributes, etc. All these latter items are framework (message suite) issues.
In my opinion, software (environments) systems that automatically infer and
retain design-intent as a natural and integrated part of the “authoring” process, and
subsequently allow it to be formally managed in team development environments with
minimal complexity are the new “holy-grail”.
Just my usual opinions ;-)
What do you other folks think?
- Dave Simmons
Quasar Knowledge Systems, Inc. [QKS], dsimmons@qks.com
You Didn’t Need Those New Features Anyway, Did You?
Great magazine and great article on Drag & Drop in your June 94 issue - but I
have a problem. Like many developers, I am using a third party’s class library to
implement my applications (in my case, TCL).
It’s all very well for Apple to bring out (excellent) extensions to the OS like
Drag & Drop, but if you are tied to a class library (whose destiny you don’t control) it
may as well not exist. I looked at retrofitting D&D into TCL 1.1.3 and decided that I
would have to override 30odd classes to provide D&D. It isn’t worth the effort.
Firstly, it’s an incredible amount of work, and secondly I would effectively end up with
my own version of TCL - which I would then have had to convert to TCL 2.0 and beyond!
I note that TCL 2.0 still doesn’t support Drag & Drop.
In the future, can Apple apply some pressue (god knows how) on vendors of
developer tools to incorporate these extensions into their class libraries so that they
can be released con currently? If these new extensions are taken up earlier by
developers, it’s good business for Apple.
I have an application which screams for D&D right now, but I’ll have to work
around that until Symantec gets TCL to support D&D.
- Craig McFarlane
Delaney & Morgan Computing Pty. Ltd., Australia
Referenced by (2):